home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1996 November: Tool Chest / Dev.CD Nov 96 TC / Dev.CD Nov 96 TC.toast / What's New? / Development Kits / Apple Game Sprockets / NetSprocket 1.0.1 / NetSprocket Release Notes next >
Encoding:
Text File  |  1996-09-12  |  7.0 KB  |  148 lines  |  [TEXT/CWIE]
  1. NetSprocket 1.0.1
  2. Release Notes
  3. ---------------
  4.  
  5. Please report all bugs to sprockets@adr.apple.com!
  6.  
  7.  
  8. What's New?
  9. -----------
  10.  
  11. NetSprocket 1.0.1 is a bug-fix for NetSprocket 1.0, and contains no new 
  12. features.  Two important bugs were fixed in this version:
  13.  
  14. 1.  The Human Interface functions caused PPP clients that were configured
  15. to automatically dial in to their ISP when an application requested a
  16. connection would dial in when the dialogs appeared, rather than when the
  17. OK button was hit.  This was a side-effect of NetSprocket's attempt to
  18. determine whether or not the TCP/IP setup was valid.  This version now
  19. assumes that if TCP/IP is present, it is configured correctly.  This 
  20. assumption has two effects.  First, PPP will only dial in when the OK
  21. button is hit.  Second, the user may try to host or join a game on TCP
  22. when in fact their TCP/IP configuration is invalid, leading to a lengthy
  23. pause before control is returned to the application.
  24.  
  25. 2.  There was a bug in the endpoint code that could cause NetSprocket to
  26. become confused about where one Reliable message ended, and another began.
  27. This would happen if the game was rapidly (30x/second) sending Registered
  28. messages, interspersed with an occasional large (1k+) message.  This has
  29. been fixed.
  30.  
  31. The bug described below about AppleTalk crashing under certain conditions
  32. has been isolated as an OpenTransport problem.  This bug has been fixed
  33. in OT 1.1.1.
  34.  
  35.  
  36. Release Components
  37. ------------------
  38.  
  39. NetSprocket Release Notes                - this file
  40. NetSprocket.h                             - the header file to compile with.
  41. NetSprocketLib                           - release version of the library
  42. NetSprocketDebugLib                       - debugging version of the library
  43. NetSprocketTest                           - test program
  44. NetSprocketTest.ยต                        - Code Warrior 9 project to build test
  45. NetSprocketTest Sources                    - sources for test program
  46.  
  47. Note:  NetSprocketTest uses Metrowerks' PowerPlant, and requires CW8 or later
  48. to build.
  49.  
  50. WARNING: don't place both the debugging and non-debugging versions of the
  51. library in the search path or you will not be sure which version you will be
  52. using.
  53.  
  54. Dependencies
  55. ------------
  56.  
  57. NetSprocket requires OpenTransport version 1.1 or later.  1.1 is the version
  58. that is installed by the System 7.5 Update 2.0, or the System 7.5.3 installer.
  59.  
  60. NetSprocket requires the latest Universal Headers -- version 2.1.2 or later.
  61. You can find them on E.T.O. #20, the MacOS SDK CD-ROMs, Apple's web-site, or
  62. a number of other locations.
  63.  
  64. Compatability with Prereleases
  65. ------------------------------
  66.  
  67. NetSprocket 1.0.1 is fully compatible with NetSprocket 1.0
  68.  
  69. Getting the Most out of NetSprocket
  70. -----------------------------------
  71.  
  72. To get the optimal performance out of NetSprocket, design your game to send
  73. "Normal" messages that contain less than 550 bytes of data.  This allows
  74. NetSprocket to use datagram-level delivery for both TCP/IP and AppleTalk. 
  75. Using "Registered" messages can cause a 2-50% network performance degradation,
  76. depending on a number of factors, including network bandwith, utilization,
  77. message size, and send frequency.
  78.  
  79. All messages, except ones sent from a player to himself, are sent through the
  80. host.  Therefore, the host is one "hop" from any other player, and two non-host
  81. players are always two "hops" apart.
  82.  
  83. Sending a message to a group is not as efficient as sending to everyone in the
  84. game, or to a single player.  It is usually more efficient than sending to each
  85. individual in the group separately.
  86.  
  87. You CAN NOT send messages at VBL (or any other interrupt) time with NetSprocket
  88. 1.0.  You should schedule a deferred system task, or just wait until system
  89. task time before sending.  You CAN however, call NSpMessage_Get at interrupt
  90. time.  We generally recommend against all interrupt-time calls to the Game
  91. Sprockets, as doing so will pretty much guarantee that your code will not run
  92. under MacOS 8.
  93.  
  94. The number of players in a NetSprocket game is limited only by memory (and
  95. networking resources, such as available ports).  If you exepect to handle lots
  96. of players (14+), you need to make sure you give NetSprocket sufficient memory
  97. and queue elements when you initialize it.  If you get send failed or memory
  98. error message from NetSprocket, try giving it more memory.
  99.  
  100. If you have a situation where your game has players whose network throughput is
  101. greatly disparate, you need to make sure you don't choke the slow person.  For
  102. example, if you have 4 players on AppleTalk over Ethernet, and you have a fifth
  103. player join the game over a 28.8k PPP connection, and your fast machines are
  104. sending messages 30 times a second each, you're going to quickly gag the
  105. newcomer with too much data, and the host will simply not be able to deliver
  106. messages as quickly as you generate them.  The newcomer will be disconnected
  107. after approximately 20 messages have been queued up, waiting for flow control
  108. to lift before delivering them.  You can avoid this type of problem by
  109. throttling down your game's send rate to allow the newcomer to participate. 
  110. You can also avoid it by sending "Junk" messages instead of Normal.
  111.  
  112. NetSprocket 1.0 does not implement Round-Trip-Time or throughput functions,
  113. though the next release will.  You can implement your own RTT and thruput
  114. functions on top of the NetSprocket API yourself, though.
  115.  
  116. Known Bugs
  117. ----------
  118.  
  119. There is a bug that causes games playing over AppleTalk to crash in the
  120. following situation:  If any client (joiner) in the game crashes, and anyone
  121. else in the game continues to send Registered messages to that client (since
  122. the other players aren't notified that the player is gone until a timeout
  123. period is reached), then the host machine may crash when the application quits. 
  124. In network-ease, the host will start getting flow control errors when the
  125. client crashes (or reboots or somehow leaves the game in a disorderly fashion). 
  126. In response, the host queues up up to 20 messages, then generates a "player
  127. left" message.  When the OpenTransport endpoint is closed (by quitting the
  128. game), the outstanding T_GODATA notifications have not fired for their
  129. corresponding flow control errors.  This seems to cause OT to go into an
  130. infinite loop, waiting for flow to lift so it can notify the client.  The user
  131. will experience a freeze, but the mouse will still move.  They can force quit,
  132. but generally the state of their system is too hosed to do anything useful. 
  133. Needless to say, we're working on the problem.  It doesn't happen with TCP/IP,
  134. and it doesn't happen if you're using Normal or Junk messages smaller than 550
  135. bytes.
  136.  
  137. If you are a joiner in a game, then leave in some disorderly fashion, then join
  138. another game (or host one yourself), it is possible that OpenTransport will
  139. assign you the same port you were using before for you previous game.  If this
  140. happens, you may receive spurious messages from the other game, if it is still
  141. in progress, and if the timeout period for disconnecting you (about 2 minutes)
  142. has not elapsed.  This is not a bug per-se, but should be handled better by
  143. NetSprocket.
  144.  
  145. Host renegotiation isn't working properly.  We're working on it for the next
  146. release.
  147.  
  148.